Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/1162

Internet Message Format | 1994-08-27 | 14.1 KB

Date: Sat, 30 Jul 1994 16:52:42 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Re: Digest
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <Pine.3.87.9407301642.A26054-0100000@grad>
Mime-Version: 1.0
Precedence: bulk

Evan:

]Its a bug in the AES.  I get it too.  Sometimes, I just get clicks with
]background windows instead of a top.  I get it in TOSWIN alot, which is
]when I have lots of windows open, so that could be part of it.  I just
]jam the mouse into the menu bar and then click (since I usually have
]window everywhere, and the menu bar is the only place uncovered!)

If my guess is correct, then it is not a bug in AES.  Rather,
graf_dragbox and form_button use evnt_multi!  And since evnt_multi
obviously will not send repeated WM_TOPPED messages to the same window
while the mouse is held down, then graf_dragbox and form_button will not
work.  graf_mkstate, on the other hand, works just great.

]Your solution .. you said you were simulating mouse events.  How did
]you do this.  I wanna see how much it changes the code I posted previously.
]Since the code I posted allowed some pretty radical behavior (the use
]of the other mouse buttons during a drag!) and I don't want to lose
]that flexibility.  In fact, I don't want to call any graf_ functions
]or anything else that creates a mode.  I want to flow everything though
]evnt_multi() with an optimized binding (no stack usage, etc) and doll
]out the events to other objects from there.

My solution was to write my own form_button which does nothing
spectacular.  It just does everything that the normal form_button (took
me a lot of guess work, but I can't tell any difference between mine and
the normal one), except that mine will work even if the object is
partially obscured.

Writing my own form_button solved the problem of it locking up.  The
second problem was to get repeated mouse events to a background window.
Since evnt_multi win't sent repeated WM_TOPPED messages, I have to handle
everything after I get the first one, *plus I have to make sure the mouse
button it up before the next evnt_multi call*.

I have one routine that handles WM_TOPPED events, and another that
handles MU_BUTTON events.  When I get a WM_TOPPED message for a
background window that is 'backactive', I get the current mouse position
and other information and send it to my routine that handles the
MU_BUTTON events, thereby simulating a button event on the background window.

To do drags and to make sure that the button is up before the next
evnt_multi (when my WM_TOPPED handling routine returns to the caller), I
have a loop in my WM_TOPPED handler that keeps getting mouse positions
and information as long as the button is held down.  As soon as the
button is let up, it returns to the calling routine.

This works great.  The only problem is that while the button is down, the
operations of my library are trapped within itself, not getting back to
evnt_multi.  But since you can't use evnt_multi anyway, there's no point
in arguing about it.  However, since my library doesn't use wind_update
(since it's not using VDI, it doesn't need to, plus a developer is
responsible for doing it for his own window drawing, PLUS since you're
dragging around in a window, you couldn't move the mouse pointer to the
menu bar to fowl anything up), no activities in other windows would be
bothered with much.


]========================================================================
]Well, I break my library down into a few seperate .C files and the
]programmer can pick which ones he wants.  I'm sure that's what most of
us do.
]========================================================================
]
]Nope, you put EVERY function in a separate C file, roll the whole thing
]into a .a or .lib or what have you, and then whatever functions the
]programmer uses will be included by the linker.  The linker includes
]entire .o files, so the programmer doesn't choose, the LINKER chooses.
]This requires libraries to have TONS of files.  Makes a MINIX filesystem
]very handy, but that is beside the point.

Sounds icky, but I'll see what I can do.  I think, though, I will cut it
up after I'm done.

But there is one thing I need to mention... some of my functions use
other functions that only THEY use and are not needed to be accessed from
any where else.  Should I put them into the same O file?

How do I create an A or LIB file?  What is the difference between the
two?  I've never looked into this before.



About app-defs:

AVOID scancodes it the app-defs file.  It's easy enough to tell the
difference between Backspace and Ctrl-H (or Return/Enter/Ctrl-M, etc...)
regardless of where H is because while H may move, Backspace won't and
Ctrl-H is then just any key that produces an ascii code of 7 what ISN'T
the Backspace key.  It's quite simple.  Therefore, only specify ASCII
codes in the app-defs file for the letter keys.  Anything else like
Return, Enter, Backspace should, however, be referenced by scancode.
Plus, it's safe to do that because THEY don't move.


Oh, and there's another problem with app-defs... if you don't have a TSR
to load it (of course translate it into something useful) and put it in
one place in memory, then you'll have every app with its own copy of the
file.  On the other hand, the TSR creates a load of its own problems, not
the least of which is the fact that the app is going to have to figure
out whether it should use the default key or determine if the user's put
one in there to customise it just for that app.


]Huh?   No, no, no.  Like this:
]
]*.*.autoSave.yes
]*.*.confirmAtExit.yes
]*.YourApp.autoSave.no
]*.TosWin.autoSave.no
]
]Get it?  Now everything but YourApp and TosWin will autosave.  Everything
]confirms at exit.  You can still manually save.  You don't have to change
]anything.  In fact, the file is pretty static.  You only need to change
]it to change global settings or to change a specific application to do
]something different than the global settings you've installed.  You edit
]less because if you turn off a global feature, that program you haven't
]used in 3 months doesn't have to be reconfigured!

I don't like this particular example.  There are some things that you
MIGHT want to configure in a global file, but auto-save isn't one of
them.  IF an app has auto-save, I would think that it should keep track
of it in its OWN config file.


Everyone seems to be bent on making the app-defs file an ASCII file.
While I can see the clear benefits (user editable with an ASCII text
editor, etc.), I can see some clear draw-backs.  If it's an ASCII file,
any utility manipulating it will have to delete it and write a new one
any time a change is made because the size of the file would change
(although this isn't much of a big deal), plus it's harder to parce
(because if it's binary data, you don't have to parce at all!).


Evan:

]Thread2 - this waits on any number of file handles, although it only
]needs to wait on one (optional timeout).  It blocks until the
]device is has data ready to be read or written.  When Fselect returns,
]Fread as much data from the file handle (raw mode) as you can,
]with standard GEMDOS Fread() with a whatever maximum you like (you
]can use whatever you like, or dynamically change the size if Fread
]reads your entire buffer, then double the size so it doesn't fill
]up anymore!)  After you read all the data, update your windows
]internal and external structures.  Key events are still echoed
]directly to the modem, even during redraw.  Once you've done the
]update, call Fselect again and wait for more modem data.  This thread
]will block when there is no modem IO to read.

This sounds very interesting.  I'll have to figure out Fselect.
One problem I have with modem I/O is that GEMDOS does not seem to provide
a way for me determine how many characters are there before using Fread.
As a result, I have to use Fread (or Bconin) repeatedly, reading one
character until Bconstat says there are no more characters.

I have a couple or routines that read directly from the Iorec structure
and read the buffer directly.  It works VERY fast.  Would this interfere
with MultiTOS?

How do I find out how many characters are there that I can read?

What is the file handle of the serial port?

Evan, you mention Fread having a raw-mode?  GEMDOS does not translate and
strip off cr's from cr/lf's.  And it does not wait for an EOL before
returning to the program.  It reads as many bytes as you tell it and then
returns.

If I Fread x bytes from the serial port, does it wait until it gets x
bytes or does it return after it reads as many as it can?


For local echo, I would have both the main program and the threaded I/O
routine call the same function to deal with putting characters on the
screen.  I just have to be careful that they don't clash... I'd have the
main program wait until the thread was done.


Some day, I MAY get back to writing ANSI Link.  :)  But first I'll have
to finish my library and then rewrite ANSI Link to use the library.


]========================================================================
]My library can now do dragging of active and passive sliders in
]background windows, as well as buttons.  It also handles all of these
]things using the rectangles list so they come out properly if partially
]obscured.
]========================================================================
]
]Hmm .. how?  You don't get any events until you release the button!
]What sort of hackery is this?   Could you post the code?  Or email
]it to [e-mail]?

I have posted descriptions of this before and in this message.  If
they're not clear, please ask questions.


]========================================================================
]You have an Atari book that needs to be published?  Two Worlds Publishing
]can do it for you.  :)
]========================================================================
]
]The internet frowns on commercial advertising .. can you have a
]shareware publishing company?

Where?  When?  I see commercial developers mentioning product releases in
public and on announce groups all the time.  PLUS, this is email, so I
can say just about anything I want (within reason because it is KINDA
public being on a mailing list).

Or are you just pulling my leg here?


Ofir:

]We must be a bunch of extremely lucky people who have not been oplagued by
]this problem. There was a 97% majority against you last time I looked. And
]I don't think it's surprising. In fact, if there was a majority otherwise
]I would have unsubscribed as such a result would go totalloy against the
]idea of this mail list.

Would you have unsubscribed indeed?  How childish of you.  Yet you bashed
me for suggesting that I might unsubscribe because of the exact opposite.

You seem to have the attitude that what you say is correct and what I say
is NOT, simply because you disagree with me.

I have a good reason with physical evidence against using Ctrl-A for
Select All.  We've been over this countless times.  You, on the other
hand, have no PHYSICAL support... you cop out and claim that you want to
keep it just because 'people have used it before'.  All through history,
people have done all sorts of stupid things just because 'lots of other
people did it too'.  This doesn't make it right.

Would it have gone against the idea of the mailing list?  Perhaps... if
the idea of this mailing list is to blindly make standards, regardless of
any danger they might they might cause.

On the other hand, if the idea of this list is to make GOOD standards,
then my suggestion is certainly the more logical.

You seem to believe that common use has priority over saftey.  This is wrong.

Saftey comes first, then useability, THEN common use.

As we all well know, humans can do some pretty stupid things (wars,
crimes, flat-earth society, prejudice, slavery, the US congress, etc.),
yet the fact that a few people or a majority do something doesn't make it
right.

Some people use Ctrl-A for Select All.  Mostly on other machines where
Ctrl is NOT next to A.  Nay, let's say a majority use Ctrl-A for Select
All (most of whom are using other keyboards where Ctrl is not next to
A).  This doesn't make it right for an Atari keyboard where Ctrl IS next
to A.

On the A, one places their little finger, a weak finger that does not
quite have the dexterity of the others.  This finger can easily slip JUST
A LITTLE to the left, and since there is practically no inter-key spacing
on the Atari keyboard, this little finger will then hit the Ctrl key as
well as the A key.

It is QUITE CLEAR how easy it is to accidentally hit Ctrl-A, yet you wish
to assign something as dangerous as Select-All to it?

Think clearly about the physics of the human hands, the fact that most
people are not experienced typists, and the shape of the Atari keyboard.
You developers have been typing for decades, and while you may be
self-taught (as am I), you are much better typists than the average
person using the keyboard.  This average person will have a tremendously
higher chance of slipping and hitting Ctrl-A then you would.  You are not
plagued by this problem, but THEY ARE!

Empathise with the user.  Pretend you have weak, untrained fingers and
THEN type.  Think not about what works well for you as a programmer, but
what works well for the average users.  Now, one of the things I like
about Atari programs is that they are written with interfaces that the
programmer likes, and I, being a programmer, like them as well.  However,
you should not forget about the average user.

Whatever the direction of your user interface, though, you should avoid
doing anything stupid.



]I speak to hundreds of users through the Atari ST Review helpline - none of
]them uses MiNT, most do not even know what it is. A complex app-defs file
]like you are suggesting is a recipe for dissaster for these users.

Bravo!  Quite true!  Again, we need to Keep It Simple, Stupid.

Anything that corresponds to something very application-specific should
be kept in the app's own config file.  Auto-save, whatever.

And again, I don't even very much like the idea of maintianing keys in a
global file anyway.



---------------
Ani rotse harbeh kesef.
Ich moechte vill geld.
Don't we all?